Acorn Risc Technologies StrongARM CD-ROM/Acorn Risc Technologies StrongARM CD-ROM.iso/ftp/documents/acornusr/1989/jul89

Text File | 1996-02-28 | 3.7 KB | 60 lines

29/01/90
* Welcome to another Customer Hotline column. This will be my last column,
but more on this later.

* With the release of RISC OS comes a new 6502 emulator called !65Host.
This application substantially emulates a BBC model B microcomputer
running OS 1.2. It supports direct screen accesses, paged sideways ROMs
and direct accesses to some hardware. As a result, the Customer Support
department would like your help in compiling lists of software that work
under this emulator, the 65Arthur Tube emulator and the PC emulator. If
you know of any packages which run under these emulators, please write in,
stating which version of the package you have used, what problems you have
encountered, which emulator (and version of emulator) and which computer
you are using.

* If you have ever wondered how space allocation under DFS & ADFS
differes, or have been stumped by the concept of compaction, read on!
Unlike DFS, ADFS has provision for extending files beyond the space
allocated to them on a disc. On DFS, space is contiguous for a file, and
each file has a space on the disc, starting from a particular sector
number recorded in the catalogue. If there is space after the file on the
disc, the file can expand, but only until the point on the disc where
another file starts, or the end of the disc is reached. Compaction in DFS
removes all free space between files, and therefore no file (except the
last file on the disc) can expand beyond the end of it's final sector. The
last file on a disc may be identified as the file which comes FIRST in a
*INFO #.* operation on the disc. In ADFS, the file storage is still
contiguous (except for E format under RISC OS on the Archimedes), but file
expansion beyond the end of the space available is possible. This is
achieved by physically copying the file to a different place on the disc,
where more space is available. The place on the disc previously occupied
by the file then becomes vacant. The obvious corollory of this is that for
a file to expand beyond the allocated space, there must be a contiguous
space on the disc available of MORE than the space currently occupied by
the file itself. This is of particular importance in database
applications, where files may expand. If a file is stored so that it has
to expand, the best place for it is as the last file on the ADFS disc.
However, there is no simple way for the user to determine which file is
last on the disc. Therefore in, for example, a ViewStore application, it
is sensible for the actual file holding the database information to be on
a disc by itself (in this case the D.file) and other smaller
"housekeeping" files to be on another disc. This means that there is no
obstacle to file expansion. ADFS is, in this manner, like DFS. It is
possible to create files before use on a blank disc (on a Master 128 and
later, use *CREATE), with the last file being created being the database
file itself. Then, each file will have its own area to occupy. However,
this method can backfire if one of the smaller files gets too large - it
will be copied in front of the database file, potentially causing an
obstacle to its expansion. If the file tries to expand beyond its length
and is physically too large to copy onto the free space available, it will
report "Disc full" or the potentially more confusing "Compaction
required". NB It should be noted that in both DFS and ADFS, compaction
removes space between files, reducing the capability of earlier files on
the disc to expand without copying.

* As I mentioned at the beginning, this will be my last Customer Hotline
column. However, as so many of you have thanked BBC Acorn User and myself
for this column, I have bullied one of my colleagues into taking it over.
I will leave him to introduce himself next month.